feat: process GutenbergKit media uploads with app Media settings - #25824

Description

Ref CMM-1249. Ref CMM-2155.

Related:

• feat: process GutenbergKit media uploads per the app's media settings WordPress-Android#23142

Integrates GutenbergKit's native media upload pipeline (wordpress-mobile/GutenbergKit#357) so device media picked in GutenbergKit is processed natively before upload, honoring the app's Media settings: Optimize Images, Max Image Upload Size, Image Quality, Max Video Upload Size, and Remove Location From Media. Previously these uploads went directly from the WebView to the REST API with no processing, bypassing the settings the legacy editor and My Site > Media already honor.

How it works

• GBKMediaUploadProcessor implements GutenbergKit's MediaUploadDelegate. When the editor uploads a device file, GutenbergKit's localhost upload server hands the staged file to processFile, which configures MediaImageExporter or MediaVideoExporter with the same option mapping as MediaImportService:
  • Images are resized/recompressed per the Optimize Images settings, GPS EXIF is stripped per Remove Location, and non-web-safe formats (e.g. HEIC) are converted to JPEG, mirroring ItemProviderMediaExporter.
  • Videos are always transcoded per the Max Video Upload Size preset, matching the legacy iOS path (MediaImportService sets the preset unconditionally) and unlike Android, where video optimization is opt-in. The free-plan 5-minute duration limit is checked as a safety net, but the editor rejects video on free WP.com plans against the site's allowed mime types first, so videoLimitExceeded should rarely be what a user hits.
  • GIFs, SVGs, and non-media files pass through untouched (GutenbergKit forwards the original bytes verbatim); disallowed file extensions are rejected with the standard localized error.
  • When processing would be a no-op (optimization and location stripping disabled, web-safe format), the original file passes through without re-encoding.
• handlesFile declines files the processor provably won't touch — GIFs, and documents on a site with no extension restriction to enforce — so GutenbergKit forwards the original request body without first copying the file to disk. Images and videos are always claimed: what happens to them depends on Media settings or on the file's contents, and declining is unrecoverable because the delegate never sees the file again. A parity test asserts that anything declined would have returned .original, across the settings matrix.
• Upload itself still uses GutenbergKit's default uploader, which relays the raw WordPress REST response to the editor, so attachment objects, sub-sizes, and error notices behave identically to a direct upload.
• Wired unconditionally in PostGBKEditorViewController (covers posts, pages, and custom post types). If GutenbergKit's upload server cannot start, it degrades gracefully to the standard WebView upload path.

Handling uploads the editor describes imprecisely

The multipart headers are less trustworthy than they look, and two cases made valid uploads fail outright before being fixed here:

• No file extension. GutenbergKit names its temp file after the multipart filename, and the editor doesn't guarantee that carries an extension — its native inserter derives one from a URL path segment (media.url.split('/').pop() || 'media'). Resolving the type from the path alone yields public.data, which conforms to no media type, so the export was rejected and the editor saw a 500 for a file that previously uploaded fine. The type now falls back to the reported MIME type, and exports go through the concrete exporter rather than MediaURLExporter, which re-derives the type from the extension in exportURL and would reject the file a second time. MediaImageExporter reads the type from the file's contents via CGImageSourceGetType.
• MIME types that need normalizing. Content-Type may carry parameters and arbitrary casing (RFC 9110 §8.3), and GutenbergKit's multipart parser substitutes text/plain for a part that sent no Content-Type at all (RFC 7578 §4.4) — it picks the file part by the presence of a filename parameter, not by content type. Left as-is, image/jpeg; charset=binary resolves to a dynamic type conforming to nothing, and a real photo announced as text/plain looks like a document. Parameters are stripped, casing lowered, and the placeholder types treated as absent, falling back to the filename extension.

Temporary file handling

Each export gets its own temporary directory. Destination names come from URL.incrementalFilename(), a check-then-act fileExists loop with no locking, and GutenbergKit handles each connection in its own task, so a shared directory let two concurrent exports of the same source name resolve to the same path and clobber each other. Nothing sweeps that directory either — GutenbergKit removes only the file it is handed, and MediaFileManager's cleanup covers the uploads directory alone — so a failure after the export wrote a file abandoned a full-size payload for the lifetime of the container. The failure path now cleans up after itself.

Notes

• EXIF orientation. The no-op passthrough skips the legacy exporter's unconditional orientation normalization, so a sideways-shot photo uploads with its orientation flag intact rather than rotated into its pixels. This is deliberate. That normalization dates to May 2017 and predates WordPress 5.3 (Nov 2019), whose wp_create_image_subsizes rotates server-side for every site, self-hosted included. Baking in a rotation the server performs anyway would cost a lossy re-encode of a photo the user explicitly asked not to optimize. Android rotates here, but as a port of the same pre-5.3 workaround — and it already passes flagged files through untouched on WP.com. See Editor: vertical images appear horizontal in previews and on the web for self-hosted and Jetpack sites #12703 and core changeset 46202.
• Divergence from legacy. The no-op passthrough itself is a deliberate difference: the legacy path always re-encodes, and with optimization off imageQualityForUpload still returns .high, so legacy rewrites a JPEG at quality 0.9. Passing the original bytes through avoids that generation loss. It only applies when the user has turned off both Optimize Images and Remove Location, which both default to on.
• Uploaded attachments are not inserted into the local Core Data Media store, so My Site > Media shows them after the next sync. This matches GutenbergKit's pre-existing behavior; syncing after upload is a possible follow-up.
• Blog.videoDurationLimit only returns a limit for free WP.com sites, which are the same sites whose allowed_file_types exclude video. The limit is kept for defense in depth — it still applies if the editor's mime-type filtering changes or a site allows video on a free plan — but it isn't the path a user takes today.
• No shared media code is modified. The production diff is GBKMediaUploadProcessor.swift (new) and five lines of PostGBKEditorViewController.swift, both under NewGutenberg/, plus the GutenbergKit dependency bump. Legacy Gutenberg and Aztec select different view controllers in EditorFactory and never construct this processor.

Testing instructions

2. Image resize: In App Settings > Media, enable Optimize Images with Max Image Upload Size 2000. Open a post in GutenbergKit, add an Image block, and upload a photo larger than 2000px from the device. Verify the upload succeeds and the stored full-size image is at most 2000px (inspect the attachment in wp-admin or the block's URL).
3. No-op passthrough: Disable Optimize Images and Remove Location From Media, upload the same photo, and verify it retains its original dimensions and file size (the original bytes should be uploaded unchanged).
4. Location stripping: Enable Remove Location From Media, upload a GPS-tagged photo, download the original from the site, and verify it has no GPS EXIF data.
5. HEIC: Upload a HEIC image via the Files app and verify it arrives as JPEG.
6. GIF: Upload an animated GIF and verify it still animates on the published post.
7. Portrait photo: With Optimize Images off, upload a photo shot in portrait orientation and verify it appears upright on the published post (WordPress rotates it server-side).
8. Video: On a site that allows video, set Max Video Upload Size to 480p, upload a video, and verify the transcoded resolution.
9. Disallowed type: On a free WordPress.com site, try to insert a video. Verify the editor shows a notice that the file type is disallowed.
10. Multiple at once: Select several photos in one go and verify every one uploads intact, with no missing or duplicated images.
11. Verify behavior on both a WordPress.com site and a self-hosted site with an application password.